A provider edge network may apply advanced subscription based services to packets through service path based chaining of the different advanced subscription based services. By way of example, an upstream (also commonly referred to as an uplink) packet from a subscriber may be forwarded to a subscriber terminating entity. The subscriber terminating entity may access per-subscriber service characterization information in order to determine an upstream service path that is appropriate for the upstream packet. The upstream service path may identify both services that are to be applied to the upstream packet, and an order in which the different services are to be applied to the upstream packet. The subscriber terminating entity may add an upstream service path identifier (ID) to the upstream packet, and then forward the upstream packet to the first service engine along the upstream service path. The first service engine may perform its associated service on the upstream packet. The first service engine may then use the upstream service path ID to identify the next service engine along the path where the upstream packet is to be forwarded. Similarly, other service engines along the upstream service path may forward the upstream packet according to the upstream service path ID.
However, one challenge with service path based chaining approaches is that determination of downstream service paths for downstream packets (e.g., transmitted from a provider end station toward a subscriber end station) tends to be more difficult to implement than determination of upstream service paths. When a downstream packet is received at a line card, typically the line card is not provisioned with per-subscriber service policy information, since this would generally tend to be scale-wise prohibitive. In one possible approach the line card may simply forward the packet to the subscriber terminating entity to allow the subscriber terminating entity to determine the appropriate downstream service path. One drawback is that this may result in the subscriber terminating entity needing to process the downstream packet twice, once at the beginning of the downstream service path (e.g., in order to determine the downstream service path), and again at the end of the downstream service path (e.g., to forward the downstream packets to an external element through the line cards). When the amount of packet traffic is high, this may significantly limit the performance of the subscriber terminating entity.
In some prior approaches, the line card may use an Access Control List (ACL) based approach to determine the downstream service path. However, such ACL based approaches tend to have certain drawbacks. For example, with ACL based service chaining, subscriber application steering knowledge generally has to be known to the forwarding controller. For example, in ACL based approaches, the downstream service path is generally determined based primarily on the source port of the downstream packet identifying a particular type of service or application. For example, a source port of 80/8080 may identify Hypertext Transfer Protocol (HTTP), a source port of 443 may identify Hypertext Transfer Protocol Secure (HTTPS), a source port of 20 may identify FTP, a source port of 25 may identify SMTP (e.g., email), and a source port of 3724 may identify gaming applications. The downstream service path determination is highly subscriber application dependent, which tends to limit the applicability of the ACL based approaches. Also such ACL based service chaining approaches are generally limited to service paths involving no more than generally about two different services. Furthermore, the ACL rules are generally statically programmed or configured on the line cards, rather than being dynamically adapted or learned during runtime. This tends to make changing or adding rules more difficult. Additionally, provisioning all of the line cards with the ACL rules may be scale-wise prohibitive when the number of subscribers is high.
In yet another conventional approach, the line card determines the service path and inserts metadata in the packet header in order to specify the order in which the services are to be applied on the packet. The drawback with such an approach, however, is that the metadata must be carried in the packet header, which may not be feasible with various applications. Further, such an approach requires the line card to perform flow learning in the downstream direction (thus, rendering the solution not scalable) or requires the downstream traffic to be sent to the subscriber management entity multiple times (thus, rendering the solution inefficient).